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Abstract 


This memo defines a portion of the Management Information Base (MIB) 
for use with network management protocols in the Internet community. 
In particular, it defines objects for monitoring and controlling 
network devices with APPN (Advanced Peer-to-Peer Network) EBN 
(Extended Border Node) capabilities. This memo identifies managed 
objects for the EBN architecture. 
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1.0 Introduction 


This document is a product of the SNA NAU Services MIB Working Group. 
It defines a MIB module for managing devices with Advanced Peer-to- 
Peer Networking (APPN) Extended Border Node (EBN) capabilities. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119, reference 
[13]. 


2.0 The SNMP Network Management Framework 


The SNMP Network Management Framework presently consists of six major 
components. They are: 


[o] the overall architecture, described in RFC 2271 [7]. 


Oo the SMI, described in RFC 1902 [3], - the mechanisms used for 
describing and naming objects for the purpose of management. 


o the MIB-II, STD 17, RFC 1213 [2], - the core set of managed 
objects for the Internet suite of protocols. 


o the protocol, STD 15, RFC 1157 [1] and/or RFC 1905 [6] and/or RFC 
2272 [8] -- the protocol for accessing managed information. 


o the user-based security model defined in RFC 2274 [10]. 


o the view-based access control model defined in RFC 2275 [11]. 


Textual conventions are defined in RFC 1903 [4], and conformance 
statements are defined in RFC 1904 [5]. Common applications are 
defined in RFC 2273 [9]. 


The Framework permits new objects to be defined for the purpose of 
experimentation and evaluation. 


This memo specifies a MIB module that is compliant to the SMIv2. A 


MIB conforming to the SMIv1 can be produced through the appropriate 
translation. 
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3.0 Overview 


This document identifies the proposed set of objects for monitoring 
the configuration and active characteristics of devices with EBN 
capabilities. The Extended Border Node function is an APPN 
enhancement for an APPN network node (NN). It supports topology 
isolation, subnet interconnection, and session establishment between 
subnets. 


In a single APPN network, all network topology information is 
propagated to all network nodes. Directory searches can also be 
forwarded to all network nodes. As the network grows, this network 
traffic could become prohibitive. Also, in networks where different 
enterprises are connected via APPN, it may be desirable to shield an 
enterprise from the network traffic of another enterprise.  EBNs 
allow customers to partition a network into subnets to reduce or 
shield such network traffic. 


An EBN provides this function by blocking topology information 
exchange between subnets, and controlling where directory searches 
are forwarded. A subnetwork is a cluster of APPN NNs which share the 
same network topology.  Subnetwork boundaries, or partitions, occur 
where an EBN and an NN adjacent to it have different network 
identifiers (NETIDs). They may also occur where an EBN and adjacent 
NN have the same NETID but are configured to have a subnetwork 
boundary. 


The connection between two APPN nodes is an APPN transmission group 
(TG). A TG at a subnet boundary is called an Intersubnetwork 
Transmission Group (ISTG). 


The subnet in which an EBN resides is called its native subnetwork. 
The subnet across the subnet boundary is called the non-native 
subnetwork, with respect to the EBN. 


A cost of the EBN function is that customers may have difficulty 
determining the end-to-end route of sessions that cross subnet 
boundaries, and understanding how the EBN will control directory 
searches between subnets. This MIB addresses these issues. 


Another challenge facing customers is to identify subnet boundaries 
formed by EBNs. The SNANAU APPN MIB [14] identifies subnet 
boundaries in the appnNnTopology group. The SNANAU APPN MIB provides 
management of APPN objects, and contains some tables that are 
extended by this MIB. 


In this document, we describe EBN managed objects. 


Clouston & Moore Standards Track [Page 3] 


RFC 2457 Extended Border Node MIB November 1998 


The EBN terms and overall architecture are available from the 
networking.raleigh.ibm.com ftp site [15]. 


Highlights of the management functions supported by the EBN MIB 
module include the following: 


o 


o 


o 


o 


Identifying the subnet affiliation of LUs (logical units) 
Identifying session routes in non-native subnets, with 
correlation to the route in the native subnet provided in the 
SNANAU APPN MIB. 

Identifying the COS (Class of Service) mappings between subnets. 


Identifying the subnet routing lists 


This MIB module does not support: 


Configuration of EBN nodes. 
Historical information about session initiation failures. 


Peripheral Border Node (PBN) support. PBN is an APPN function 
that only supports communication to adjacent subnetworks, and is 
not expected to be widely implemented. 


Traps. The APPN MIB contains a trap for Alert conditions that 
may affect EBN resources. Although no APPN/EBN Alerts are 
defined today in the APPN MIB [14], they could exist in the 
future. The value for the affectedObject object contained in the 
alertTrap is determined by the implementation. It may contain a 
VariablePointer from the EBN MIB. 


3.1 EBN MIB Structure 


The EBN MIB module contains the following groups of objects: 


o 


o 


ebnDir - subnet information about LUs. 

ebnIsRscv - provides the RSCV (Route Selection Control 

Vector) and COS for the subnetwork on the BIND destination side 
of the EBN. 

ebnDirConfig - objects related to the EBN directory. 


ebnCos - COS mapping between subnetworks, 
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fe) ebnSubnetRoutingList - the customer-supplied list of where to 
forward search requests. 


[e hbn - HPR (High Performance Routing) EBN intermediate session 
information. 


These groups are described below in more detail. 
3.1.1 enbDir group 
The ebnDir group contains the ebnDirTable, which is an extension to 


the appnDirTable. It specifies the subnet affiliation of LUs in the 
EBN's directory. 


3.1.2 ebnIsRscv group 


The ebnIsRscv group contains the ebnIsRscvTable, which is an 
extension to the appnIsInTable. The appnisInTable only allows for 
the RSCV and COS name for one subnetwork traversed by a session. 
This extension contains the RSCV and COS name for the other 
subnetwork. 


When an EBN changes RSCVs before forwarding a BIND, appnIsInRouteInfo 
contains the incoming RSCV, and ebnIsRscvDestinationRoute contains 
the outgoing RSCV. 


The following three cases illustrate the contents of 
appnlIsInRouteInfo and ebnIsRscvDestinationRoute at Extended Border 


Nodes. 


1. EBN connected to another EBN 


**subnet 1**|----- STG -————- |**subnet 2** 
EBN1 EBN2 
PLU SLU 
Eo teas ii ates ese in ate des >| 
(f. j= >| 
(2) |==- > 
(3) 


PLU = Primary Logical Unit (session initiator) 
SLU Secondary Logical Unit (session destination) 


The value of the appnIsInRouteInfo object at EBN1 is the RSCV 
containing the route, represented by (1), from the PLU (or the 
entry EBN in its subnet) to EBN2. The value of 
ebnIsRscvDestinationRoute object at EBN1 is the RSCV, represented 
by (2), containing the one-hop route from EBN1 to EBN2. The 
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appnlIsInRouteInfo object at EBN2 also contains the RSCV 
represented by (2). The value of ebnlIsRscvDestinationRoute in 
EBN2 is the RSVC containing the route to the SLU (or to the next 
subnet's entry EBN), represented by (3). 


2. EBN connected to a NN or PBN 


**subnet 1**|----- ISTG -————- |**subnet 2** 
EBN1 NN/PBN 
PLU SLU 
Soe Sean a eee eae > | 
(1) |Sesscemeucoscoeuieuesceeueiuer > 
(2) 


The value of the appnIsInRouteInfo object at EBN1 is the RSCV 
containing the route from the PLU (or the entry EBN in its 


subnet) to the NN or PBN, represented by (1). The value of the 
ebnIsRscvDestinationRoute object at EBN1 is the RSCV containing 
the route from EBN1 to the SLU, represented by (2). Note that 


the SLU must be in subnet 2, because the entry node is an NN or 
PBN rather than an EBN. The appnIsInRouteInfo object at NN/PBN 
contains the same RSCV, as represented by (2). 


3. NN or PBN connected to EBN 


**subnet 1**|----- ISTG 5----- |**subnet 2** 
NN/PBN EBN1 
PLU SLU 
E ea See oS SS > | 
(1) [esegue cene > 
(2) 


The value of the appnIsInRouteInfo object at the NN/PBN is the 
RSCV containing the route from the PLU to EBN1, represented by 
(1). Note that the PLU must be in subnet 1, because the exit 
node is an NN/PBN rather than an EBN. The appnIsInRouteInfo 
object at EBN1 contains the same RSCV. The value of the 
ebnlIsRscvDestinationRoute object at EBN1 is the RSCV containing 
the route from EBN1 to the SLU (or the next subnet’s entry border 
node), as represented by (2). 


The following three cases illustrate the contents of 
ebnIsRscvDestinationCos at Extended Border Nodes. 
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1. EBN connected to another EBN 


**subnet 1**|----- ISTG -——--- |**subnet 2** 
EBN1 EBN2 
PLU SLU 
COS A 
SoS Soe Se te a SS ea es > | 
COS B 


PLU = Primary Logical Unit (session initiator) 
SLU Secondary Logical Unit (session destination) 


The value of ebnIsRscvDestinationCos object at EBN1 is COS A. 
The value of ebnIsRscvDestinationCos object at EBN2 is COS B. 


2. EBN connected to a NN or PBN 
**subnet 1**|----- ISTG;----2-— |**subnet 2** 
EBN1 NN/PBN 
PLU SLU 
COS A 
elc e »| 
COS B 


The value of the ebvIsRscvDestinationCos object at EBN1 is COS B. 


3. NN or PBN connected to EBN 


**subnet 1**|----- TISTG ----—-2 |**subnet 2** 
NN/PBN EBN1 
PLU SLU 
COS A 
echo Sa e ET eat Ge itn ere cue t > | 
COS B 
|---------- > 


The value of the ebnIsRscvDestinationCos object at the EBN2 is 
COSB. 


3.1.3 ebnDirConfig group 


The ebnDirConfig group consists of simple objects that provide EBN- 
specific information about directory caching and the local default 
value for the maximum number of subnetworks a LOCATE search procedure 


may traverse. 
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3.1.4 ebnCos group 


The ebnCos group contains the ebnCosMapTable, which specifies how COS 
values are mapped between the non-native subnetwork and the native 
subnetwork. 


3.1.5  ebnSubnetRoutingList group 


The ebnSubnetRoutingList group contains information about the 
customer-supplied EBN subnetwork routing list, which indicates to 
which adjacent nodes an EBN will forward LOCATE search requests. It 


consists of the following tables: 


1.  ebnSubnetSearchTable 


This table has an entry for each LU name that has a defined 


subnet routing list. The LU name may identify a single LU, or it 
may contain a wildcard character that could identify a group of 
LUs (partial wildcard) or all LUs (full wildcard). The objects 


in the table indicate whether the EBN may add dynamic entries to 
the subnet routing list, and whether the subnet routing list 
entries may be reordered for better search performance. 


2. ebnSearchTable 


This table has an entry for each control point name which is 
included in a multi-subnet search for a particular LU name. The 
index to the table is the LU name to be searched for, and an 
index which lists the order in which the CP names are to be 
searched. Both the CP name and the LU name entries in the table 
allow for partial and full wildcards. The CP name also allows 
for special entries that indicate that the EBN will search 
itself and its own native subnetwork at this point in the search, 
or will search all native EBNs. 


3.1.6 hbn group 


The hbn group contains information about HBN (HPR EBN) intermediate 
sessions. The hbnlIsInTable is an extension to the appniIsInTable. 
This table is present for intermediate sessions when there are back- 
to-back RTP (Rapid Transport Protocol) connections in an HBN. It 
provides the NCE ID (network connection endpoint identifier) and TCID 
(transport connection identifier) for the second RTP connection. 
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4.0 Definitions 
EBN-MIB DEFINITIONS ::= BEGIN 


IMPORTS 
MODULE-IDENTITY, OBJECT-TYPE, Unsigned32 
FROM SNMPv2-SMI 
MODULE-COMPLIANCE, OBJECT-GROUP 
FROM SNMPv2-CONF 
DisplayString, TEXTUAL-CONVENTION 
FROM SNMPv2-TC 
SnaControlPointName 
-- Because the characters allowed in an SNA control 
-- point name come from a restricted character set, 
-- these names are not subject to internationalization. 
FROM APPN-MIB 
snanauMIB 
FROM SNA-NAU-MIB; 


ebnMIB MODULE-IDENTITY 
LAST-UPDATED "98042818002" -- April 28, 1998 
ORGANIZATION "IETF SNA NAU MIB WG / AIW APPN MIBs SIG" 
CONTACT-INFO 
" 

Bob Clouston 

Cisco Systems 

7025 Kit Creek Road 

P.O. Box 14987 

Research Triangle Park, NC 27709, USA 

Tel: 1 919 472 2333 

E-mail: clouston@cisco.com 


Bob Moore 

IBM Corporation 

BRQA/501 

P.O. Box 12195 

Research Triangle Park, NC 27709, USA 
Tel: 1 919 254 4436 

E-mail: remoore@us.ibm.com 


DESCRIPTION 
" The MIB Module for Extended Border Node" 
:= { snanauMIB 7 } 


-— snanauMIB ::= { mib-2 34 } 
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—— KK KK kck ck ck ckck ck ck ck ck ck ck kck ck ck ck ck ck ck ck ck ck ck ckck ck ckck ck ckck k ck ck ck ckck ck ck ck ck ck ck ck ck ck ck ck ck ck k ck ck k ck kk k kk 


-— Textual Conventions 


SnaNAUWildcardName ::— TEXTUAL-CONVENTION 
STATUS current 
DESCRIPTION 
"Fully-qualified network NAU name. Entries take one of three 
forms: 


- Explicit entries do not contain the character '*'. 

- Partial Wildcard entries have the form 'ccc*', where 
'ccc' represents one to sixteen characters in a legal 
SNA NAU Name. 

- A full wildcard consists of a single character '*'. 


Because the characters allowed in an SNA NAU name come from 
a restricted character set, these names are not subject to 
internationalization." 


SYNTAX DisplayString(SIZE(1..17)) 


—— o Ckckckck ck ckck ck ckck ck ck ck ck ck ck ck ck ck ckck ck ckck ck ckck ck ckck ck ckck ck ckck ck ckck ck ck ck ck ck ck ck ck ck ck ck ck ck ck ck ck ck ck ck k ck k k k kk 


ebnObjects OBJECT IDENTIFIER ::= { ebnMIB 1 } 


—— KK KK KKK KKK ck ck ck ck ck ck ck ck ck ck ck ck ck ck ck ck ck ck ckck ck ck ck ck ckck ck ck ck ck ckck ck ck ck ck ck ck ck ck ck ck ck ck ck ck ck ck k ck kk k kk 


— 0 Ckckckckckckckck ckckck ck ckckckckckck ckckckck ck ck ck ck ck ck Ck kk ck kk Ck Ck Ck Ck kk S x x Kk Kk ko ko ko ko ko kock ko 
-- EBN Directory Group 


-- The ebnDirTable is an extension to the appnDirTable. It specifies 


-- the subnet affiliation for LUs in the EBN's directory. 
— KKK KKK KKK ckck ckckckck ckckck ckckckck ck ckckckckckckock KKK KK KK ck ck ck ck ck ok ck ck ockockockckckockck ck ckckck ck kckck k kk kk 


ebnDir OBJECT IDENTIFIER ::= { ebnObjects 1 } 


ebnDirTable OBJECT-TYPE 

SYNTAX SEQUENCE OF EbnDirEntry 

MAX-ACCESS not-accessible 

STATUS current 

DESCRIPTION 
"The EBN Directory Table. This table is an extension 
to the APPN MIB's appnDirTable. Entries in this table 
are in one-to-one correspondence with entries in the 
appnDirTable, with corresponding entries having identical 
values for their respective indexes." 


:= { ebnDir 1 } 
ebnDirEntry OBJECT-TYPE 


SYNTAX EbnDirEntry 
MAX-ACCESS not-accessible 


Clouston & Moore Standards Track [Page 10] 


RFC 2457 Extended Border Node MIB November 1998 


STATUS current 
DESCRIPTION 

"Entry in the EBN Directory Table." 
INDEX { ebnDirLuName } 


:= { ebnDirTable 1 } 


EbnDirEntry ::= SEQUENCE { 
ebnDirLuName SnaNAUWildcardName, 
ebnDirSubnetAffiliation INTEGER } 


ebnDirLuName OBJECT-TYPE 
SYNTAX SnaNAUWildcardName 
MAX-ACCESS not-accessible 
STATUS current 


DESCRIPTION 
"Fully qualified network LU name in the domain of a serving 
network node. If this object has the same value as the 


appnDirLuName object in the APPN MIB, then the two objects 
are referring to the same LU." 


::= ( ebnDirEntry 1 } 


ebnDirSubnetAffiliation OBJECT-TYPE 
SYNTAX INTEGER { native (1), 
nonNative (2), 
subarea (3) } 
MAX-ACCESS read-only 
STATUS current 


DESCRIPTION 
"Specifies the subnetwork affiliation of the LU: 
- native (1) : The LU is in the native APPN subnetwork. 
- nonNative(2) : The LU is in a non-native APPN subnetwork. 
- subarea (3) : The LU is in a subarea network." 


:= { ebnDirEntry 2 } 


—— KK KKK KK KKK ck ck ck ck ck ck ck ck ck ck ck ck ck ck ck ck ck ck ck ck ck KKK KKK ckck ck ckck ck ck ck ck ck ck ck ck ck ck ck ck ck ck ck kc k ck k kk kk 


-- EBN Intermediate Session RSCV Group 

-- This table is a sparse extension to the appnIsInTable. For 

-- sessions crossing ISTGs adjacent to the EBN, it contains the RSCV 
-- and COS used in the direction of the BIND destination. 


—— o Ckckckck ck ck ck ck ckck ck ck ck ck ck ck ck ck ck ck ck ck ck ck ck ck ck ck ck ck ck ckck ck ckck ck ckck ck ckck ck ck ck ck ck ck ck ck ck ck ck ck ck ck ck ck k ck k kk kk 


ebnIsRscv OBJECT IDENTIFIER ::= { ebnObjects 2 } 


ebnIsRscvTable OBJECT-TYPE 
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SYNTAX SEQUENCE OF EbnIsRscvEntry 

MAX-ACCESS not-accessible 

STATUS current 

DESCRIPTION 
"The EBN Intermediate Session RSCV table. This table is an 
extension to the appnIsInTable. It contains the RSCV and COS 
used in the direction of the BIND destination. There is an 
entry in this table for each session that traverses an ISTG 
when it enters or leaves this EBN, with corresponding entries 
having identical values for their respective indexes." 


::= ( ebnIsRscv 1} 


ebnIsRscvEntry OBJECT-TYPE 
SYNTAX EbnIsRscvEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 

"Entry in ebnIsRscvTable." 
INDEX ( ebnIsRscvCpName, 
ebnIsRscvPcid } 


::= ( ebnIsRscvTable 1 } 


EbnisRscvEntry ::= SEQUENCE { 
ebniIsRscvCpName SnaControlPointName, 
ebnIsRscvPcid OCTET STRING, 
ebnIsRscvDestinationRoute OCTET STRING, 
ebnIsRscvDestinationCos DisplayString } 


ebniIsRscvCpName OBJECT-TYPE 

SYNTAX SnaControlPointName 

MAX-ACCESS not-accessible 

STATUS current 

DESCRIPTION 
"The network-qualified control point name of the node at 
which the session and PCID originated. For APPN and LEN 
nodes, this is either CP name of the APPN node at which 
the origin LU is located or the CP name of the NN serving 
the LEN node at which the origin LU is located. For DLUR 
resources it is the name of the owning SSCP. 


If this object has the same value as the appnIsInFqCpName 
object in the APPN MIB, then the two objects are referring to 


the same APPN control point." 


::— ( ebnlIsRscvEntry 1 } 
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ebnIsRscvPcid OBJECT-TYPE 
SYNTAX OCTET STRING (SIZE (8)) 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 
"The procedure correlation identifier (PCID) of a session. 
It is an 8-octet value. 


If this object has the same value as the appnIsInPcid object 
in the APPN MIB, and if the corresponding ebnIsRscvCpName 
object has the same value as the corresponding 
appnlIsInFqCpName object, then the entries indexed by these 
objects are referring to the same session." 


:= ( ebnIsRscvEntry 2 ] 


ebnIsRscvDestinationRoute OBJECT-TYPE 
SYNTAX OCTET STRING(SIZE (0..255)) 
MAX-ACCESS read-only 


STATUS current 
DESCRIPTION 
"The route selection control vector (RSCV x'2B') used in the 


direction towards the SLU." 
::= ( ebnIsRscvEntry 3 } 


ebnIsRscvDestinationCos OBJECT-TYPE 
SYNTAX DisplayString (SIZE (1..8)) 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 
"The Class of Service (COS) name used in the direction 
towards the SLU. 


Because the characters allowed in an SNA COS name come from 
a restricted character set, these names are not subject to 
internationalization." 


::— ( ebnlIsRscvEntry 4 } 


kkxkxkxkxkxkxkxkxkxkxkkxkxkkkkkkxkkkxkkkkxkkkxkkkkxkkkxkkkkxkkkxkkkxkxkkkxkkxkkxkkkkkkxkkkxkxx*k 
-- EBN Directory Config Group 
-- The following simple objects provide information about EBN 


-- directory. 
kkxkxkxkxkxkxkxkxkxkxkxkxkkkkxkkkxkkkxkkkkkkkxkkkkkkkxkkkxkxkkkkkkxkxkkkxkkkkkkkkkkkkkxkxx*k 


ebnDirConfig OBJECT IDENTIFIER ::= { ebnObjects 3 } 
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ebnSearchCacheTime OBJECT-TYPE 
SYNTAX Unsigned32 
UNITS "minutes" 
MAX-ACCESS read-only 
STATUS current 


DESCRIPTION 
"The amount of time in minutes an extended border node will 


retain information about a multi-subnetwork search, once 
that that search terminates. A value 0 indicates that the 
EBN has no defined limit, and the number of entries is 
bounded only by memory." 


::= ( ebnDirConfig 1 } 


ebnMaxSearchCache OBJECT-TYPE 
SYNTAX Unsigned32 
UNITS "entries" 
MAX-ACCESS read-only 
STATUS current 


DESCRIPTION 
"The maximum number of multi-subnet entries to be cached. 


The value 0 indicates that the local node has no defined 
limit, and the number of entries is bounded only by 
memory." 


::= ( ebnDirConfig 2 ] 


ebnDefaultSubnetVisitCount  OBJECT-TYPE 

SYNTAX Unsigned32 

UNITS "topology subnetworks" 

MAX-ACCESS read-only 

STATUS current 

DESCRIPTION 
"The default maximum number of subnetworks a LOCATE search 
procedure may traverse." 


:= ( ebnDirConfig 3 } 


CkCkCck ckCck ck ckck ck ckck ck ck ck ck okck ck ck ck ck ckck kck ck kck ck ckck ck ck ck ck ck ck ck ckck ck ck ck ck ck ck ck ck ck ck ck ck ck ck ck ck ck k k k k kk 


-- EBN COS Mapping Group 

-- The ebnCosMap Table specifies how non-native COS values are mapped 
-- to COS values defined in the native subnetwork. The COS mappings 
-- that an EBN performs are determined by multiple factors, one of 

-- which is a set of user-defined mappings. This table returns the 
-- COS mappings that the EBN is actually performing, rather than 


-- the user-defined mappings. 
kkxkxkxkxkxkxkxkxkxkkxkxkxkxkxkxkxkxkxkkkxkxkkkxkkkxkkkxkxkxkkxkxkkxkxkkkxkxkxkxkxkkkxkxkkxkkkkxkkkkkkxkxx*k 
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ebncos OBJECT IDENTIFIER ::= { ebnObjects 4 } 


ebnCosMapTable OBJECT-TYPE 

SYNTAX SEQUENCE OF EbnCosMapEntry 

MAX-ACCESS not-accessible 

STATUS current 

DESCRIPTION 
"The EBN COS Mapping Table. This table specifies how non- 
native COS values are mapped to COS values defined in the 
native subnetwork. 


Note: The COS mappings that an EBN performs are determined 
by multiple factors, one of which is a set of user-defined 
initial mappings. This table returns the COS mappings that 
the EBN is actually performing at the time it is queried, 
rather than the user-defined initial ones." 


::= { ebnCOS 1 } 


ebnCosMapEntry OBJECT-TYPE 
SYNTAX EbnCosMapEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 
"An entry in the EBN COS Mapping table." 


INDEX { ebnCosMapCpName, 
ebnCosMapNonNativeCos } 


:= ( ebnCosMapTable 1 } 


EbnCosMapEntry ::= SEQUENCE { 
ebnCosMapCpName SnaNAUWildcardName, 
ebnCosMapNonNativeCos DisplayString, 
ebnCosMapNativeCos DisplayString } 


ebnCosMapCpName OBJECT-TYPE 
SYNTAX SnaNAUWildcardName 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 
"Fully qualified network CP name for which the COS mapping 
applies." 


:= ( ebnCosMapEntry 1 } 


ebnCosMapNonNativeCos OBJECT-TYPE 
SYNTAX DisplayString (SIZE(1..8)) 
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MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 
"This object contains one of the following values: 


- An 8-character COS name used in a non-native subnetwork. 

- The single character '*', identifying the entry with the 
default native COS for a non-native CP name. This entry 
is used when there is no entry in the table for a 
non-native CP name / non-native COS pair. 


Because the characters allowed in an SNA COS name come from 
a restricted character set, these names are not subject to 
internationalization." 


::= ( ebnCosMapEntry 2 } 


ebnCosMapNativeCos OBJECT-TYPE 
SYNTAX DisplayString (SIZE(1..8)) 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 
"An 8-byte name for the class-of-service, as known in the 
native subnetwork. 


Because the characters allowed in an SNA COS name come from 
a restricted character set, these names are not subject to 
internationalization." 


:= ( ebnCosMapEntry 3 } 


—— o Ckckckck ck ck ck ck ck ck ck ck ck kock ck ck ck ck ckck ck ckck ck ckck ck ckck ck ck ck ck ckck ck ck ck ck ck ck ck ck ck ck ck ck ck ck ck ck ck ck ck ck ck k ck ck k kk kk 


-- EBN Subnet Routing List Group 

-- The EBN Subnet Routing List indicates to which nodes an EBN 

-- forwards search request. This group contains information 

-- pertaining to the CONFIGURED Subnet Routing List at an EBN. How a 
-- particular search request is routed is determined by a transient 
-- list that the EBN creates based on the configured list and other 


-—- factors. 
—— Ckckckckckck ckckckckckck ck ck KKK KKK KKK ck ckckckckckck ck ck ck ck ckckckckckck ck ck ckckockckckckck ck ck ck ck ckckckckck ck ck ck ck ck ck ck kk 


ebnSubnetRoutingList OBJECT IDENTIFIER ::= { ebnObjects 5 } 


ebnSubnetSearchTable OBJECT-TYPE 
SYNTAX SEQUENCE OF EbnSubnetSearchEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 
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"This table contains one entry for each fully qualified LU 
name for which an associated subnet routing list has been 
defined. An entry in this table contains general 
characteristics of the subnet search routing list for an 
LU name. The routing list itself is represented by a set 
of contiguous entries in the ebnSearchTable." 


:= { ebnSubnetRoutingList 1 } 


ebnSubnetSearchEntry OBJECT-TYPE 

SYNTAX EbnSubnetSearchEntry 

MAX-ACCESS not-accessible 

STATUS current 

DESCRIPTION 
"An entry for the ebnSubnetSearchTable. The entry 
represents the configured parameters the EBN uses when it 
is determining how to search for the LU identified by the 
ebnSubnetSearchLuName object." 


INDEX { ebnSubnetSearchLuName } 
:= { ebnSubnetSearchTable 1 } 


EbnSubnetSearchEntry ::= SEQUENCE { 
ebnSubnetSearchLuName SnaNAUWildcardName, 
ebnSubnetSearchDynamics INTEGER, 
ebnSubnetSearchOrdering INTEGER } 


ebnSubnetSearchLuName OBJECT-TYPE 
SYNTAX SnaNAUWildcardName 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 
"Fully qualified network LU name." 


::= { ebnSubnetSearchEntry 1 } 


ebnSubnetSearchDynamics OBJECT-TYPE 
SYNTAX INTEGER { none(1), 
limited (2), 
full (3) } 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 
"Indicates whether an EBN may add dynamic entries to a 
subnetwork routing list.  none(1) means no entries may be 
added to the subnetwork routing list.  limited(2) means 
only likely entries may be added to the subnetwork routing 
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list.  full(3) means all native extended border nodes and 
adjacent, non-native EBNs and NNs will be added to the 
subnetwork routing list." 


::= { ebnSubnetSearchEntry 2 } 


ebnSubnetSearchOrdering OBJECT-TYPE 
SYNTAX INTEGER{ priority(1), 
defined(2) } 

MAX-ACCESS read-only 

STATUS current 

DESCRIPTION 
"Indicates whether an EBN may reorder a subnetwork routing 
list so that entries which are more likely to be successful 
move to the top of the subnetwork routing list and entries 
which are more likely to be unsuccessful move to the bottom 
of the list. 
The following values are defined: 


- priority(1): Entries may be reordered. 
— defined(2): Entries must not be reordered." 


::— ( ebnSubnetSearchEntry 3 ] 
-—- Border node search table 


ebnSearchTable OBJECT-TYPE 

SYNTAX SEQUENCE OF EbnSearchEntry 

MAX-ACCESS not-accessible 

STATUS current 

DESCRIPTION 
"This table indicates the CONFIGURED list of control points 
to which the EBN sends Locate searches for a given fully 
qualified LU name. Each entry in the table indicates one 
control point that should be included in a multi-subnet 
search for a particular LU name." 


::= { ebnSubnetRoutingList 2 ] 


ebnSearchEntry OBJECT-TYPE 

SYNTAX EbnSearchEntry 

MAX-ACCESS not-accessible 

STATUS current 

DESCRIPTION 
"An entry in the ebnSearchTable. An entry can exist in 
this table only if an entry exists in the 
ebnSubnetSearchTable with an ebnSubnetSearchLuName value 
matching this entry's ebnSearchLuName. 
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For a given ebnSearchLuName value, the ordering of entries 
provides by the ebnSearchIndex values corresponds to the 
order in which the control points to be searched appear in 
the CONFIGURED search list for the ebnSearchLuName." 


INDEX { ebnSearchLuName, 
ebnSearchIndex } 


::= { ebnSearchTable 1 } 


EbnSearchEntry ::= SEQUENCE { 
ebnSearchLuName SnaNAUWildcardName, 
ebnSearchIndex Unsigned32, 
ebnSearchCpName DisplayString, 
ebnSearchSNVC Unsigned32 } 


ebnSearchLuName OBJECT-TYPE 

SYNTAX SnaNAUWildcardName 

MAX-ACCESS not-accessible 

STATUS current 

DESCRIPTION 
"Fully qualified network LU name. If this object has the 
same value as the ebnSubnetSearchLuName object, then the 
two objects are referring to the same LU." 


::— { ebnSearchEntry 1 } 


ebnSearchIndex OBJECT-TYPE 
SYNTAX Unsigned32 
MAX-ACCESS not-accessible 
STATUS current 


DESCRIPTION 
"Secondary index enumerating the CONFIGURED order in which 
a search is forwarded to CPs for a particular LU name. The 


order for an actual search is determined dynamically by the 
EBN, based on this configured information and on other 
factors, including whether search dynamics and search 
ordering are enabled. Information on these last two settings 
is available in, respectively, the ebnSubnetSearchDynamics 
and ebnSubnetSearch ordering objects." 


::= { ebnSearchEntry 2 } 


ebnSearchCpName OBJECT-TYPE 
SYNTAX DisplayString (SIZE(1..17)) 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 
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"This object specifies the CP(s) to which a search should be 
forwarded. It either follows the SnaNAUWildcardName textual 
convention or takes one of the following special formats: 


'*' indicates that all native EBNs and all adjacent non- 
native EBNs and NNs may be added to the routing list 
dynamically, 


'*SELF' indicates that the EBN should search itself and 
its native subnetwork at this time during the 


cross-subnet search, 


'*EBNS' indicates all native EBNs. 


Because the characters allowed in a CP name come from a 
restricted character set, and because the three formats 
listed here use no special characters, this object is not 
subject to internationalization." 


::= ( ebnSearchEntry 3 } 


ebnSearchSNVC OBJECT-TYPE 
SYNTAX Unsigned32 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 
"The maximum number of subnets a Locate search procedure may 
traverse. " 


:= ( ebnSearchEntry 4 } 


—— KK KK ck ck ck ck ckck ck ck ck ck ck ck ck ck ck ck ck ck ck ck ck ckck ck ck ck ck ck ck ck ckck ck ckck ck ck ck ck ck ck ck ck ck ck ck ck ck ck ck ck ck k ck k ck k k kk kk 


-- HPR Extended Border Node Intermediate Session Group 

-- The hbnIsInTable is a sparse extension to the appnIsInTable. 
-— For sessions that use back-to-back RTP connections in an HBN, 
-- this table provides the network connection endpoint identifier 
-- (NceId) and the transport connection identifier (Tcid) for the 


-— second RTP connection. 
—— KK KK KKK ckckckckckck ck ck ck ckckckckck ck KKK KKK KKK ck ck ckockckckckckckck ck KKK KKK KKK KKK KKK KKK ck ck ck ck ck kc 


hbn OBJECT IDENTIFIER ::- { ebnObjects 6 } 


hbnIsInTable OBJECT-TYPE 
SYNTAX SEQUENCE OF HbnIsInEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 
"The HBN Intermediate Session table." 
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::— ( hbn 1} 


hbnlIsInEntry OBJECT-TYPE 

SYNTAX HbnIsInEntry 

MAX-ACCESS not-accessible 

STATUS current 

DESCRIPTION 
"Entry of the HBN Intermediate Session Table. An entry 
exists in this table for every intermediate session being 
routed between back-to-back RTP connections in the HBN. 


When an entry for a session exists in this table, the 
Ncelds and Tcids for the back-to-back RTP connections are 
made available in the following four objects: 


RTP connection in the direction of the PLU: 
- NceId:  appnIsInRtpNceId (in the APPN MIB) 
= Teid: appnIsinRtpTcid (in the APPN MIB). 


RTP connection in the direction of the SLU: 
- NceId: hbnIsInRtpNceId (in this table) 
= Teid: hbnIsInRtpTcid (in this table)." 


INDEX { hbnIsInFqCpName, 
hbnIsInPcid } 


::= { hbnIsInTable 1 } 


HbnIsInEntry ::= SEQUENCE { 
hbnIsInFqCpName SnaControlPointName, 
hbnIsInPcid OCTET STRING, 
hbnIsInRtpNceId OCTET STRING, 
hbnIsInRtpTcid OCTET STRING } 


hbnIsInFqCpName OBJECT-TYPE 

SYNTAX SnaControlPointName 

MAX-ACCESS not-accessible 

STATUS current 

DESCRIPTION 
"The network-qualified control point name of the node at 
which the session and PCID originated. For APPN and LEN 
nodes, this is either the CP name of the APPN node at 
which the origin LU is located or the CP name of the NN 
serving the LEN node at which the origin LU is located. 


If this object has the same value as the appnIsInFqCpName 


object in the APPN MIB, then the two objects are referring 
to the same APPN control point." 
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::= ( hbnrisInEntry 1 } 


hbnlIsInPcid OBJECT-TYPE 
SYNTAX OCTET STRING (SIZE(8) ) 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 
"The procedure correlation identifier (PCID) of a session. 
It is an 8-octet value. 


If this object has the same value as the appnIsInPcid object 
in the APPN MIB, and if the corresponding hbnIsInFqCpName 
object has the same value as the corresponding 
appnlIsInFqCpName object, then the entries indexed by these 
objects are referring to the same session." 


::= ( hbnIsInEntry 2 } 


hbniIsInRtpNceld OBJECT-TYPE 
SYNTAX OCTET STRING (SIZE(1..8)) 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 
"The HPR local Network Connection Endpoint of the session in 
the direction of the SLU." 


::= ( hbnIsInEntry 3 } 


hbnlIsInRtpTcid OBJECT-TYPE 
SYNTAX OCTET STRING (SIZE(8)) 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 
"The RTP connection local TCID of the session in the direction 
of the SLU." 


:= ( hbnIsInEntry 4 } 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


-— Conformance Statement 
CK CK Ck Ck Ck Ck KKK KKK KK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KK KKK kA A ko ko 


ebnConformance OBJECT IDENTIFIER ::= { ebnMIB 2 } 
ebnCompliances OBJECT IDENTIFIER ::= { ebnConformance 1 } 
ebnGroups OBJECT IDENTIFIER ::= { ebnConformance 2 } 


-- Compliance statements 
ebnCompliance MODULE-COMPLIANCE 
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STATUS current 

DESCRIPTION 
"The compliance statement for the SNMPv2 entities which 
implement the ebnMIB." 


MODULE -— this module 


-- Unconditionally mandatory groups 
MANDATORY-GROUPS { 
ebnDirectoryGroup, 
ebniIsRscvGroup, 
ebnDirectoryConfigGroup, 
ebnCosMappingGroup, 
ebnSubnetRoutingListGroup } 


-- Conditionally mandatory groups 
GROUP hbnisInGroup 
DESCRIPTION 
"The hbnIsInGroup is mandatory only for HPR extended border 
nodes." 


:= {ebnCompliances 1 } 


-- Group definitions 
ebnDirectoryGroup OBJECT-GROUP 
OBJECTS { ebnDirSubnetAffiliation } 
STATUS current 
DESCRIPTION 
"The EBN-related directory objects." 


::= ( ebnGroups 1 } 


ebniIsRscvGroup OBJECT-GROUP 
OBJECTS { ebnIsRscvDestinationRoute, 
ebnlIsRscvDestinationCos } 
STATUS current 
DESCRIPTION 
"Two objects representing RSCV and class of service 
information saved by an EBN." 


::— ( ebnGroups 2 } 


ebnDirectoryConfigGroup OBJECT-GROUP 
OBJECTS { ebnSearchCacheTime, 
ebnMaxSearchCache, 
ebnDefaultSubnetVisitCount } 
STATUS current 
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DESCRIPTION 
"The EBN Directory Configuration Group." 


::= { ebnGroups 3 } 


ebnCosMappingGroup OBJECT-GROUP 
OBJECTS ( ebnCosMapNativeCos } 
STATUS current 
DESCRIPTION 
"The EBN COS Mapping Group." 


::= ( ebnGroups 4 } 


ebnSubnetRoutingListGroup OBJECT-GROUP 

OBJECTS ( ebnSubnetSearchDynamics, 
ebnSubnetSearchOrdering, 
ebnSearchCpName, 
ebnSearchSNVC } 

STATUS current 

DESCRIPTION 

"The Subnet Routing List Group." 


::— ( ebnGroups 5 } 


hbnlIsInGroup OBJECT-GROUP 
OBJECTS ( hbnlIsInRtpNceId, hbnIsInRtpTcid } 
STATUS current 
DESCRIPTION 
"The HBN-related Intermediate Session Objects." 


::= { ebnGroups 6 } 


END 


5.0 Security Considerations 


Certain management information defined in this MIB may be considered 
sensitive in some network environments. Therefore, authentication of 
received SNMP requests and controlled access to management 
information SHOULD be employed in such environments. An 
authentication protocol is defined in [10]. A protocol for access 
control is defined in [11]. 


None of the read-only objects in the EBN MIB reports a password, user 
data, or anything else that is particularly sensitive. Some 
enterprises view their network configuration itself, as well as 
information about network usage and performance, as corporate assets; 
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such enterprises may wish to restrict SNMP access to most of the 
objects in the MIB. 


There are no read-write objects in the EBN MIB. 
6.0 Intellectual Property 


The IETF takes no position regarding the validity or scope of any 
intellectual property or other rights that might be claimed to 
pertain to the implementation or use of the technology described in 
this document or the extent to which any license under such rights 
might or might not be available; neither does it represent that it 


has made any effort to identify any such rights. Information on the 
IETF's procedures with respect to rights in standards-track and 
standards-related documentation can be found in BCP-11. Copies of 


claims of rights made available for publication and any assurances of 
licenses to be made available, or the result of an attempt made to 
obtain a general license or permission for the use of such 
proprietary rights by implementers or users of this specification can 
be obtained from the IETF Secretariat. 


The IETF invites any interested party to bring to its attention any 
copyrights, patents or patent applications, or other proprietary 
rights which may cover technology that may be required to practice 
this standard. Please address the information to the IETF Executive 
Director. 
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O0 Full Copyright Statement 
Copyright (C) The Internet Society (1998). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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